IEEE 1588 Precision Time Protocol (“PTP”) is defined in the IEEE 1588-2002 (Version 1) and 1588-2008 (Version 2) standards. IEEE 1588 has been designed as an improvement to current methods of synchronization within a distributed network of devices. It is designed for systems requiring very high accuracies beyond those attainable using Network Time Protocol (NTP). Unlike NTP, IEEE 1588 uses ‘hardware timestamping’ approach to deliver timing accuracy well under a microsecond. It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible.
IEEE 1588 is now the industry accepted packet-based method/standard to synchronize the clocks of distributed systems with high precision (accuracies in the nanosecond levels). PTP is a message based protocol that can be implemented across packet based networks including, but not limited to, Ethernet. Its underlying principle is a master/slave concept based on the regular exchange of synchronization messages. IEEE 1588 synchronizes all clocks within a network by allowing clocks to adjust their frequency/time to the highest quality clock (the GrandMaster clock).
The IEEE 1588 standard defines the set descriptors that characterize a clock, the states of a clock and the allowed state transitions. It defines network messages, fields and semantics, the datasets maintained by each clock and the actions and timing for all IEEE 1588 network and internal events. It also describes a suite of messages used for monitoring the system, specifications for an Ethernet-based implementation and conformance requirements and gives some implementation suggestions.
A complete IEEE 1588-based solution includes servo (control) algorithms, filters, and PTP-clock based on hardware timer and direct timer access. The IEEE 1588 standards define a wide range of synchronization capabilities except the clock recovery mechanisms (servo algorithm, PLL, timers, etc.) to be used at the receiver (slave) to synchronize its local clock to the master. The last pieces are vendor and proprietary solutions and are often product differentiators.
The primary challenge in designing a clock distribution system for packet networks is dealing with packet delay variations (PDVs)—that is, the variable packet transit delays. Typically, a protocol such as IEEE 1588 PTP is used for distributing timing information from a master to one or more slaves. A clock recovery mechanism at a slave then uses this timing information to recover the master clock. PDV is a direct contributor to the noise in the recovered clock and various techniques are necessary to mitigate its effects.
Packet delay variation (PDV) is therefore the main factor affecting the accuracy and stability of slave clocks when using packet timing protocols such as IEEE 1588 PTP. Packet network devices such as switches and routers introduce a variable delay to packets (PDV) that inhibits accurate path delay measurements and clock synchronization. Even for techniques that do not require path delay measurements for clock synchronization, the PDV is a direct contributor to the noise in the recovered clock. The PDV inherent in packet networks is a primary source of clock noise. The higher the clock noise, the poorer the clock quality rendering the recovered clock sometimes unusable for end system applications when the noise exceeds application defined thresholds. The term “clock noise” used herein refers to all impairments to the timing information recovered at the slave including jitter, wander, and other imperfections in the recovered clock.
For instance, for time synchronization, the variation in delay from packet to packet through the network induces noise in the slave's perception of the time at the master. Constant delay would cause a fixed offset, however variable delay causes a varying estimate of the offset. The performance of the slave is affected by both the magnitude of this variation, and how effective the slave's filter is at removing this noise.
Transparent clocks have been introduced in IEEE 1588 Version 2 to allow them to measure actual packet delays and to communicate these delay measurements to slaves. The slave can then correctly adjust its clock while compensating for the actual delay variations. This is to allow the slaves to remove the negative effects that these delay variations cause. It is an object of the present invention to provide a new clock recovery mechanism that directly accounts and compensates for PDV effects on the communication path between a master and a slave clock.
Overview of IEEE 1588v2 PTP
The GrandMaster (GM) is the root timing reference in a domain and transmits synchronization information to the clocks residing in its domain. In IEEE 1588v2 PTP messages are categorized into event and general messages. All IEEE 1588 PTP messages have a common header. Event messages are timed messages in that an accurate timestamp is generated at both transmission and receipt of each message. Event messages have to be accurately timestamped since the accuracy in transmission and receipt timestamps directly affects clock distribution accuracy. A timestamp event is generated at the time of transmission and reception of any event message. General messages are not required to be timestamped. The set of event messages consists of Sync, Delay_Req, Pdelay_Req, and Pdelay_Resp. The set of general messages consists of Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management, and Signaling.
IEEE 1588 PTP allows for two different types of timestamping methods, either one-step or two-step. One-step clocks update time information within event messages (Sync and Delay-Req) on-the-fly, while two-step clocks convey the precise timestamps of packets in general messages (Follow_Up and Delay_Resp).
The Sync, Delay_Req, Follow_Up, and Delay_Resp messages are used to generate and communicate the timing information needed to synchronize ordinary and boundary clocks (described in more detail below) using the delay request-response mechanism. A Sync message is transmitted by a master to its slaves and either contains the exact time of its transmission or is followed by a Follow_Up message containing this time. In a two-step ordinary or boundary clock, the Follow_Up message communicates the value of the departure timestamp for a particular Sync message. A Delay_Req message is a request for the receiving node to return the time at which the Delay_Req message was received, using a Delay_Resp message.
The basic pattern of synchronization message exchanges for the one-step and two-step clocks are illustrated in FIG. 1 and FIG. 2, respectively. The message exchange pattern for the two-step clock can be explained as follows. The master 1 sends a Sync message to the slave 3 and notes the time T1 at which it was sent according to its clock 4. The slave 3 receives the Sync message and notes the time of reception T2. The master 1 conveys to the slave 3 the timestamp T1 by one of two ways: 1) Embedding the timestamp T1 in the Sync message. This requires some sort of hardware processing (i.e., hardware timestamping) for highest accuracy and precision. 2) Embedding the timestamp T1 in a Follow_Up message. Next, the slave 3 sends a Delay_Req message to the master and notes the time T3 at which it was sent. The master 1 receives the Delay_Req message and notes the time of reception T4. The master 1 conveys to the slave 3 the timestamp T4 by embedding it in a Delay_Resp message.
At the end of this PTP messages exchange, the slave 3 possesses all four timestamps {T1, T2, T3, T4}. These timestamps may be used to compute the offset of the slave's clock 5 with respect to the master clock 4 and the mean propagation time of messages between the two clocks. The computation of offset and propagation time assumes that the master-to-slave and slave-to-master propagation times are equal, i.e. that there is a symmetrical communication path.
Like NTP, PTP requires an accurate measurement of the communication path delay between the time server (master) and the client (slave). PTP measures the exact message transmit time and receive times and uses these times to calculate the communication path delay and clock offset. This delay measurement principle determines path delay between devices on the network and the local clocks are adjusted for this delay using the series of messages sent between masters and slaves (FIG. 1 and FIG. 2). The one-way delay time is calculated by averaging the path delay of the transmit and receive messages. This calculation assumes a symmetrical communication path.
However, switched networks do not necessarily have symmetrical communication paths, due to the buffering process in the network nodes, which can result in asymmetrical packet delay times. To address this, PTP provides a method, using transparent clock devices (implemented in switches and routers), to measure and account for the delay experienced by PTP messages in a time interval field in the PTP messages. This setup makes the switches and routers temporarily transparent (from a synchronization viewpoint) to the master and slave nodes on the network.
Best Master Clock (BMC) Algorithm
The BMC specifies how each clock on the network determines the best clock that can serve as master in its subdomain out of all the clocks it can see, including itself. The BMC algorithm runs on the network continuously and quickly adjusts for changes in network configuration. The BMC uses the following criteria to determine the best master clock in the subdomain:                Clock quality (for example, GPS is considered the highest quality)        Clock accuracy of the clock's time base        Stability of the local oscillator        Closest clock to the GM        
In addition to identifying the best master clock, the BMC algorithm also ensures that clock conflicts do not occur on the PTP network by ensuring that clocks do not have to negotiate with one another, and there is no misconfiguration, such as two master clocks or no master clocks, as a result of the master clock identification process.
PTP Clocks
A PTP network is made up of PTP-enabled devices and devices that are not using PTP. The PTP-enabled devices typically consist of the following clock types.
GrandMaster Clock
Within a PTP domain, the GM clock is the primary source of time for clock synchronization using PTP. The GM clock usually has a very precise time source, such as a GPS or atomic clock. When the network does not require any external time reference and only needs to be synchronized internally, the GM clock can free run.
Ordinary Clock
This is a single port device that can be a master or slave within a subdomain. It can be selected as a master or slave within a segment according to the BMC algorithm. Ordinary clocks are the most common clock type on a PTP network because they are used as end nodes on a network that is connected to devices requiring synchronization. Ordinary clocks have various interfaces to external devices (end users and applications).
Boundary Clock
This is a multi-port device that can be a master or slave clock. A boundary clock (BC) 6 terminates the upstream PTP connection and initiates a downstream PTP connection. A generalised example of a boundary clock is shown in the blow-up part of FIG. 3. In general deployment, a boundary clock 6 has an internal slave clock 60 that recovers a clock. This clock 60 is then used to drive the internal master 61, which supplies the clock to the next node. Boundary clocks 6 provide an interface between PTP domains. They intercept and process all PTP messages, and pass all other network traffic. The boundary clock 6 uses the BMC algorithm to select the best clock seen by any port. The selected port is then set as a slave. The master port synchronizes the clocks connected downstream, while the slave port synchronizes with the upstream master clock.
Ordinary and boundary clocks configured for the delay request-response mechanism use the following event messages to generate and communicate timing information—Sync, Delay_Req, Follow_Up, Delay_Resp. The delay request-response mechanism is used to measure the path delay between a master and an ordinary or boundary clock. Peer-to-peer transparent clocks (see below) use a similar mechanism called the peer delay mechanism but with different PTP messages.
Transparent Clocks
The processing and buffering of packets in network devices (switches, routers, etc.) introduce variations in the time latency of packets traversing the packet network as illustrated in FIGS. 4 and 5. The variations in these delays means that the assumption that packet delay is the same in each direction is invalid, thus rendering the path delay calculations of PTP inaccurate. This issue can been addressed with the use of boundary clocks and transparent clocks.
A transparent clock (TC) does not act as a master or slave, but instead bridges these two and forwards PTP event messages and provides corrections for the residence time across the bridge. Residence time is the delay between the reception and transmission of a PTP message through a transparent clock device. These delays must be fully accounted for in the slave time offset correction. The role of transparent clocks in a PTP network is to determine certain path delay parameters and update a time-interval field (the correction field) that is part of the PTP event message header. This update allows the terminating clock to compensate for switch delays when synchronizing it clock to the master. The two types of transparent clocks are described below.
End-to-End (E2E) Transparent Clock
This is a multi-port device that is not a master or slave clock but a bridge between the two. This clock measures the message transit time (also known as resident time) in the device for (PTP event) Sync and Delay_Request messages. This measured transit time is added to the correction field in the corresponding messages as follows:
The measured transit time of a Sync message is added to the correction field of the corresponding Sync or the Follow_Up message. In the one-step mode the residence time is added to the correction field of the Sync message; in the twostep mode the residence time is added to the correction field of the Follow_Up message.
The measured transit time of a Delay_Request message is added to the correction field of the corresponding Delay_Response message.
E2E TC devices measure the delay the PTP packet resides in the TC device and increment the correction field in the PTP header as shown in FIG. 6. FIG. 7 shows the flow of PTP messages through an example network of E2E TC devices. The correction field ends up containing the sum of all the residence times that a Sync or Delay_Request message has encountered on its way through all E2E-TC network elements on the path. By doing so, the slave clock or boundary clock further down the line can determine how long the PTP packet resided in the TC devices before it. The slave clock can then use the residence times accumulated in the correction filed to mitigate the effects of PDV. This information is used by the slave when determining the offset between the slave's and the master's time. E2E transparent clocks do not provide correction for the propagation delay of the link itself between devices.
A one-step E2E TC updates for switch delay in Sync and Delay-Req messages as they pass through the switch while a two-step TC updates a field in the non time-critical general message (Follow_Up and Delay_Resp).
The process in FIG. 7 continues hop by hop (where N is the number of hops or links), and the Follow-Up (two-step mode), Sync (one-step mode) or Delay_Req (delay request response mechanism) messages maintain a running total of the residence times; resulting in a grand total delay value from master to slave. Upon receipt of the final message, the slave device calculates its offset using the running total of the residence times which is described by the following formula:
      total_residenc    ⁢                  ⁢    e_time    =            ∑              i        =        1                    N        -        1              ⁢                  ⁢          r      i      Peer-to-Peer (P2P) Transparent Clock
This is a multi-port device that is not a master or slave clock but a bridge between the two. This clock determines the residence time of a Sync message through the switch. It also determines the inbound path (link) delay as measured using the peer delay mechanism. Both values are added up and placed in the correction field of the Sync message or associated Follow_Up message as illustrated in FIG. 8. A P2P TC forwards and modifies Sync and Follow_Up messages only to compensate for residence time and peer uplink delay. The message exchange of a P2P TC is shown in FIG. 9. A one-step P2P TC updates for switch delay in Sync messages as they pass through the switch while a two-step TC updates a field in the non time-critical general message (Follow_Up).
The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P TC and the P2P TC under consideration. The correction field of the message received by the slave contains the sum of all residence times and link delays. In theory this is the total end-to-end delay (from master to slave) of the Sync packet. P2P TCs use the following event messages for peer delay measurements: Pdelay_Req, Pdelay_Resp, and Pdelay_Resp Follow_Up. These messages are sent in the sequence shown in FIG. 10.
As the process in FIG. 9 continues hop by hop (where N is the number of hops or links), the Sync or Follow-Up Messages maintain a running total of the residence and propagation times; resulting in a grand total delay value from master to slave. Upon receipt of the final Sync or Follow-Up Message, the slave device calculates its offset using the grand total delay which is described by the following formula:
      total_residence    ⁢    _time    ⁢    _plus    ⁢    _propagation    ⁢    _delay    =                    ∑                  i          =          1                          N          -          1                    ⁢                          ⁢              r        i              +                  ∑                  i          =          1                N            ⁢                          ⁢              p        i            
It is noted here that although the sum of the propagation and residence delays at each transparent clock (p1, r1, p2, r2, . . . ) is included in the Sync message's associated Follow-Up's offset correction field, the final propagation delay from transparent clock 2 to the slave device must be included in order to fully capture the end-to-end delay.
Methods for Frequency/Time Transfer
This section reviews the various methods used for frequency/time transfer using a protocol such as IEEE 1588 PTP. We focus on methods that have the capabilities of removing the negative effects that PDV has on the synchronization process.
Transfer Using Boundary Clocks
We consider here the case where all network elements on the path are BCs 6, that is a chain of clocks interconnected by individual PTP connections, one connection per hop, where each clock of the chain is slave of its predecessor and master to its successor. A BC terminates a PTP flow, extracts clock timestamps and recovers the master clock. This arrangement is shown in FIG. 11. The BC then regenerates the PTP flow and clock for downstream nodes. Effectively, the BC has both a slave clock to recover its master clock and also a master clock to regenerate the PTP packets for slave connected to it. The timing packets are generated inside the BC device. Ideally, time/frequency transfer using a BC to BC configuration has no PDV affecting the timing packets received by BC as these have been terminated in a point-to-point (link-by-link) manner. If well implemented, in a chain of BCs, there will be no accumulation of PDV from source to receiver because each timing flow is terminated at a BC and not passed through to the output.
Advantages:
This method provides good synchronization since there are no PDV effects and each node in a synchronization path locks to the upstream node directly and synchronization is traceable to the timing reference.
Note that link-by-link frequency transfer is what is used in legacy TDM networks (PDH and SDH/SONET, and even Synchronous Ethernet (ITUT Recommendation G.8261, G.8262, G.8264). Adapting IEEE 1588 PTP to do the same will move packet-based synchronization closer to that of legacy TDM synchronization which offers high accuracy synchronization services. With this capability packet technologies will offer both the advantages of packet transport and high accuracy synchronization.
Disadvantages:
As each BC recovers the clock and regenerates a new timing signal, this can lead to the introduction of clock wander (low frequency jitter i.e., jitter below 10 Hz). If a chain of BCs are used, like any chain of equipment where the clock is recovered and regenerated in each piece of equipment, then it is expected that there will be some accumulation of wander along the chain in the transferred clock frequency. The chain has to be well designed to minimize wander accumulation.
Special hardware functionality (full PTP master and slave) need to be implemented in each intermediate node involved in the synchronization chain. BCs do not propagate Sync, Follow_Up, Delay_Req, or Delay_Resp messages.
Generally, the advantages far outweigh the disadvantages, since most real life workable synchronization solutions are link-by-link in design. Furthermore, with hardware timestamping this approach offers very high accuracy synchronization and can act as alternative to synchronization solutions such as GPS.
Transfer Using Transparent Clocks
This method involves using the accumulated residence times (in E2E TCs 7) or residence plus total propagation delay (in P2P TCs) at slave to mitigate PDV effects. This configuration is shown in FIG. 12.
The IEEE 1588 does not describe how this should be done but left to vendor/user implementation. The standard does not specify how the clock recovery mechanism at the receiver should be implemented. The technique proposed in this document is one such mechanism for frequency (only) recovery at a slave using the information accumulated in the correction field of the Sync or Follow_Up messages.
Advantages:
When properly calculated, the accumulated residence times (which reflect the PDV experienced by a PTP packet) in the correction field can be used to mitigated PDV effects during clock synchronization at the slave clock.
With proper clock recovery algorithms at the slave, this method has the potential of providing good synchronization traceable to the timing reference at the slave.
Disadvantages:
Special hardware functionality (for residence time calculation and peer-to-peer delay mechanism for P2P TCs) needs to be implemented in each intermediate TC node 7 involved in the synchronization chain. TCs cannot be combined with non-PTP devices in a synchronization path between a master and a slave clock. In addition, all TC devices on a path must be of the same kind (E2E or P2P).
Depending on implementation, the internal queuing structure of the TC device may not allow an accurate calculation and update of the residence time in the correction field of a PTP message (see full discussion later). In some implementations, the queues that the timing packets will pass through before being output from the switch will introduce PDV. When PDV is not completely accounted for in a TC, the residual PDV will propagate to the slave. Hence when a chain of imperfect TCs exist in a network, residual PDV accumulation will occur.
When E2E TCs are used, there can be scalability issues for slaves that implement the path delay mechanism. A master will have to handle all slaves that implement the delay mechanism making scalability a problem if there many slaves. An implementation with P2P TCs is relatively more scalable since the peer delay mechanism involves two adjacent TCs.
Almost all of the above disadvantages related to how the TC is implemented. Ideally this approach offers good synchronization performance if the TCs are properly implemented and good algorithms are used at the slave. The discussion above shows that TCs provide a very powerful way of measuring path delays on a communication path between a master and a slave which can then be used by the slave to mitigate the effects of PDV on the recovered clock.
Packet Pre-Processing (Selection) for Clock Recovery
Another option is to transfer frequency/time in an end-to-end fashion from master to slave without involving the intermediate network nodes 8 as illustrated in FIG. 13. In this case the slave 3 is solely responsible for correctly recovering the master clock signal. Compared to the other methods, clock recovery here is more challenging because the slave 3 is exposed to all the PDV generated by the intermediate packet network 2.
The recovered clock from the PTP timing signal at the slave 3 contains clock noise (contributed largely by PDV) that needs to be removed. A filtering process is used at the slave to filter out the clock noise, thus generating a “smooth” clock output. This process is also often referred to as clock recovery. The clock recovery process in packet networks often involves two major components, a packet pre-processing module 30 and a phase-locked loop (PLL) or servo control mechanism 31 as illustrated in FIG. 14.
Packet Pre-Processing 30: This module in FIG. 14 represents the application of specialized algorithms that are used to mitigate the impact of network-induced PDV.
Phase-Locked Loop 31: This module represents a servo control function that disciplines the local clock 5 to bring its output (frequency or time) into alignment with the master's 4. The servo control function is generally present in all clock recovery mechanisms.
These two mechanisms are used together to attenuate the clock noise introduced by the packet network to levels commensurate with the clock output requirements of the application.
The two modules in FIG. 14 are outside of the scope of the IEEE 1588 standard. The packet pre-processing algorithms and PLL mechanisms are vendor implementation specific and often proprietary. These two mechanisms and the quality of the PLL oscillator 32 represent the two most important factors that determine the performance of a clock. The PLL introduces a low-pass filter characteristic in the path between the master and the slave clock output, and a high-pass filter characteristic between the local oscillator and the clock output (PLL output).
The PLL 31 has low-pass and high-pass characteristics with a common corner frequency. The bandwidth of the loop comprises the frequencies below the corner frequency. The following observations can be made about the filtering characteristics of the PLL 31:                All components of the PDV after packet pre-processing 30 entering the loop and above the corner frequency will be filtered out (attenuated) significantly. All components of the PDV after packet pre-processing 30 below the corner frequency (mostly wander, defined as noise or jitter below 10 Hz) will be passed through to the clock output.        All components of the local PLL oscillator 32 clock noise below the corner frequency will be filtered out. All components of the local oscillator noise above the corner frequency will be passed through to the clock output.        
The filtering behavior of the PLL 31 is equivalent to an “averaging” process where the time constant represents the duration over which the averaging is performed. The PLL cut-off frequency and time-constant have a reciprocal relationship and are equivalent descriptors of the low-pass filtering action.
From the above discussion we see that in the absence of packet pre-processing 30, the lowpass filtering action of the PLL 31 is solely responsible for attenuating the entire PDV so that the recovered clock will be compliant with the clock requirements of the application. To achieve this, the low-pass filter of the PLL 31 may have to be designed to have a very small cut-off frequency (meaning PLL has very small bandwidth). The drawback, however, in doing this is that the very low-pass PLL leads to a high-pass characteristic where the loop allows more local oscillator noise to pass through to the clock output. This means that the reduction of the bandwidth of the PLL 31 should not be done arbitrarily, but should take into account the quality of the local oscillator 32. It is for these reasons that applications with more stringent requirements demand higher quality oscillators. A high quality oscillator is stable and generates less noise that passes through to the clock output.
At this point, it should be appreciated that packet pre-processing 30 significantly helps to reduce the clock noise power at the PLL input and thereby can be used to alleviate the requirement of a very high quality (and expensive) oscillator. Efficient pre-processing can allow for the use of less expensive oscillators.
Advantages:
This method offers transparency to the network since timing messages can cross different types of networks (Ethernet, MPLS, Packet of SONET, Frame Relay, etc.). Only end nodes participate in time transfer, thus, method is transparent to the intermediate transport network.
There is no need for special control or processing mechanisms in the intermediate packet network, legacy asynchronous Ethernet devices do not need to be upgraded or retrofitted. No hardware modification necessary in the network equipment.
Disadvantages:
In the general case without packet pre-processing 30, synchronization performance is affected to a great extent by network design and its characteristics: traffic loading, PDV, route changes, etc. The greater the PDV, the more difficult it is to maintain synchronization between master and slave.
The network has to be carefully engineered to provide the PTP messages with the best possible quality of service (no PDV or at best very low PDV depending on end system requirements) in order to achieve high synchronization quality. There are no current guidelines on how this can be done correctly.
Even with packet pre-processing (selection), the quality of the recovered clock at the slave will depend on how well the packet selection algorithm screens out the PDV in the arriving PTP messages.
Comments on Frequency Synchronization (Syntonization) of Transparent Clock to Master
Considering the case where a TC contains a free-running oscillator with frequency accuracy no worse than ±100 ppm. If residence time is measured using this oscillator, there will be an error on the order of the residence time multiplied by the actual frequency offset. Optimum synchronization performance is obtained when all TCs on a synchronization path are frequency locked (syntonized) to the master clock. If a TC is not frequency synchronized to the GM, a TC with a ±100 ppm accuracy will contribute a measurement error of 40.0001×10 ms)=±1 μs (or ±1000 ns) to the residence time if the ideal residence time is 10 ms. A good thing is that oscillator do not typically operate at the extreme ends of their accuracy limits.
To reduce this error, IEEE 1588 Version 2 allows the TC to be syntonized, i.e., synchronized in frequency, to the GM. Each TC will use its own internal mechanisms to measure frequency offset relative to the GM and to synthesize a frequency signal that is syntonized with the GM. This synthesis may be done via hardware, firmware, or software.
In the case of a network with nodes having standard Ethernet oscillators, with nominal rates of 25 MHz for 100 Mbit/s Ethernet and 125 MHz for 1 Gbit/s Ethernet, this means that the phase measurement granularity in the TC and OC can be as much as 40 ns.
Additional phase error will result from the variable component of latency in the Ethernet physical layer (PHY) (the fixed component can be specified by the manufacturer in the design).
Now, looking at the case of a syntonized TC local oscillator. If the frequency offset between the GM and TC oscillator is measured and a syntonized frequency is created, the use of this frequency for the TC delay computation will greatly reduce the magnitude of the TC measurement errors. The phase step magnitude will now be on the order of the syntonized frequency measurement accuracy multiplied by the synch interval. For example, if the phase measurement granularity is 40 ns (assuming a 25 MHz oscillator for 100 Mbit/s Ethernet) and the TC oscillator frequency offset is measured/syntonized over 100 ms, then the measured frequency offset is 40×10−9 s/0.1 s=400×10−9=0.4 ppm (parts-per-million). The TC measurement error or offset now is (400×10−9)(0.01 s)=4 ns, i.e., the TC measurement error is reduced from the 1000 ns computed when the free-running local oscillator is used for the measurement by a factor of 250. In practice, the reduction will not be this large because other effects are present, e.g., oscillator phase noise and drifts due to temperature effects, phase measurement error due to the variable portion of the PHY latency, and frequency measurement granularity.
Thus, to conclude, the timing options available for TC for delay measurements are:                Both E2E and P2P TCs: A TC uses a local free-running oscillator embedded in the TC        Both E2E and P2P TCs: A TC uses a signal that is syntonized to the GM        P2P TCs Only: A TC uses a signal that is time synchronized to the GM. The TC computes a time offset which it uses to align its clock.        
For most accurate residence time measurements, the PTP clocks in each TC should be syntonized with the GM. Syntonization only requires correction to the TC oscillator frequency. The TC host processor can use the ingress timestamps from Sync messages to determine a frequency (rate) correction required for the PTP clock. Alternatively, syntonization may be handled on the TC host processor without adjusting the frequency of the TC clocks. The frequency correction may be used to modify the computed residence times inserted into Follow_Up and Delay_Resp messages. This method may not be used with one-step operation.